Skip to content

Conversation

@laeubi
Copy link
Contributor

@laeubi laeubi commented Jul 8, 2025

Currently we use a fixed delay for a given job priority, depending on the number of jobs running and other factors this can considerably delay some actions and make eclipse feel laggy.

This now makes these values dependent on the number of CPUs installed in the machine, as we can assume more CPUs can do the work better in parallel without additional sleep delays.

FYI @iloveeclipse @merks @vogella

I'll keep this PR open for a few days in case someone likes to review this, but the change seem save enough as I tried to even reduce the delay always to zero and didn't see any negative effects here. In many cases (e.g. no builds or other jobs running) this is even zero in some cases as the value is multiplied with the number of running jobs. In other cases it seems even unused or only used for rescheduling purpose.

Currently we use a fixed delay for a given job priority, depending on
the number of jobs running and other factors this can considerably delay
some actions and make eclipse feel laggy.

This now makes these values dependent on the number of CPUs installed in
the machine, as we can assume more CPUs can do the work better in
parallel without additional sleep delays.
@github-actions
Copy link
Contributor

github-actions bot commented Jul 8, 2025

Test Results

 1 920 files   -  27   1 920 suites   - 27   1h 25m 36s ⏱️ - 18m 42s
 4 718 tests ±  0   4 693 ✅  -   1   24 💤 ±0  0 ❌ ±0  1 🔥 +1 
14 001 runs   - 153  13 833 ✅  - 154  167 💤 ±0  0 ❌ ±0  1 🔥 +1 

For more details on these errors, see this check.

Results for commit a27a195. ± Comparison against base commit 77879f3.

@iloveeclipse
Copy link
Member

I've run JDT and JDT debug tests with this change, looks fine. In general this change makes sense, with high number of cores there is no need to wait a second for decoration thread to start, there is almost always a core free. Original code was written more than 20 years ago, highly likely on a single or dual core PC, therefore it was valid to delay "unimportant" jobs. Now on my workstation with 32 cores it is a completely different picture, delaying only wastes my time.

@iloveeclipse
Copy link
Member

I tend to merge this PR now and trigger an IBuild to see whether any unexpected side effects will appear due the timing change. Any objections?

@laeubi laeubi merged commit 3f12c83 into eclipse-platform:master Jul 8, 2025
20 of 22 checks passed
@laeubi
Copy link
Contributor Author

laeubi commented Jul 8, 2025

Alright then go a haed and trigger a build.

@iloveeclipse
Copy link
Member

@merks
Copy link
Contributor

merks commented Jul 8, 2025

@iloveeclipse @akurtakov

I'm considering whether it maybe makes sense to update the Platform's SimRel M1 contribution before tomorrow's deadline? What's your opinion? How serious/noticeable is this problem generally?

@iloveeclipse
Copy link
Member

@iloveeclipse @akurtakov

I'm considering whether it maybe makes sense to update the Platform's SimRel M1 contribution before tomorrow's deadline? What's your opinion? How serious/noticeable is this problem generally?

For me it was a deal breaker. So if the tests would not show any issues, why not?

@merks
Copy link
Contributor

merks commented Jul 8, 2025

Yes, that was my sense/guess.

I think the only potential drawback is that RAP's contribution might introduce duplicates, but I don't think those duplicates are harmful.

@mknauer

Would it be problematic to contribute a new version of the Platform to SimRel later today? When do you actually finalize the RAP contribution?

@vogella
Copy link
Contributor

vogella commented Jul 9, 2025

I todays I-Build I see a lot of errors during startup of an RCP if I do not clean-up the project before running.

Stuff like:

java.lang.Error: Unresolved compilation problems:
The import org.eclipse cannot be resolved
The import org.eclipse cannot be resolved

If I run "Project -> Clean" the the project is fine again, auto-build is active.

What I do to see the errors:

1.) Start RCP app
2.) Stop it
3.) Modify some code
4.) Start again -> errors during startup, no error markers in the IDE
5.) Clean-all and start works again

Not sure if this is related to this change but it seems to be a good candidate, so if someone else is seeing this....

@merks
Copy link
Contributor

merks commented Jul 9, 2025

It works for me:

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants